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(54) Generating service detaii records 

(57) Generalised service detail records are created 
tor a telephony service carried over a packet data net- 
work by monitoring packet network sen/lce data, signal- 



ling data and quality of service data, and combining 
these data to produce the required service detail 
records. 
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Description 

Technicai Field 

[0001 ] This invention relates to methods and appara- 
tus for generating service detail records, and to moni- 
toring systems for collecting data for these records from 
a network, such as a pacl^et data network, which is used 
tor example to carry multimedia telephony sen/ices as 
described in the International Telecommunication Un- 
ion's recommendation H.323 or the Internet Engineering 
Task Force's multimedia data and control architecture 
including the Session Initiation Protocol (SIP). These 
and similar standards define a set of protocols for es- 
tablishing sessions or calls which may include one or 
more users and one or more servers, communicating 
via one or rrK^re multimedia channels. 



and gatekeepers. 

[0005] According to a further aspect of this invention 
there is provided a method of generating generalised 
sen/ice detail records for communications carried over 
s a packet network, comprising the steps of: 

acquiring packet network service data for the pack- 
ets carrying the communications service; 
acquiring signalling data regarding at least one of 
10 call control, registration, admissions, bandwidth 
management, call status, address translation and 
intelligent network services; 
acquiring quality of service data for the service 
transmission level; and 
- combining said service data, said signalling data 
and said quality of sen/k:e data to generate gener- 
alised sen/ice detail records. 



Background 

[0002] The provision of multimedia communications 
services over a packet data network (PDN) which may 
not provide quality of service guarantees has recently 
generated a great deal of interest due to the success of 
networks based on the internet protocols (TCP/IP). Net- 
work operators are currently trialing multimedia commu- 
nications sen/ices over a variety of packet data networks 
such as Internet Protocol (IP), Frame Relay (FR) and 
Asynchronous Transfer Mode (ATM). A major problem 
is to generate service detail records (generalised call 
data records), in real-time or batch-mode, which meas- 
ure the service usage of individual users and the service 
quality that was actually experienced by the user. 

Disclosure of Invention 

[0003] According to one aspect of this invention there 
is provided a method of generating generalised sen/ice 
detail records for communications (such as telephony) 
carried over a packet network, comprising the steps of: 

acquiring packet network service data from packets 
carrying the communications; 
acquiring signalling data from a signalling protocol 
to identify at least one of addressing, configuration, 
status and timing information for endpoints, gate- 
keepers and connections involved in a call; and 
connbining said packet service data and said signal- 
ling data to generate service detail records. 

[0004] According to another aspect of this invention 
there is provided a method of discovering the network 
configuration of the endpoints, gatekeepers and their re- 
lationships, for a communications sen/ice (such as te- 
lephony) carried by a PDN, by using a passive nrranitor- 
ing system to capture the signalling messages involved 
in the configuration and negotiation of relationships, ad- 
dressing and resource allocation, between endpoints 



[0006] According to another aspect of this inverition 
20 there is provided a method of monitoring a packet data 
sub-network (e.g. ethernet segment) or link (e.g. a T3 
link carrying IP over a Point-to-Point Protocol - PPP), 
comprising the steps of: monitoring at a first location sig- 
nalling messages to detect the existence of a call; and 
25 monitoring at multiple other locations to identify some 
or all packets associated with the call (in H.323, the Call 
ID can be used to identify all packets associated with a 
given call). The captured packets may include both sig- 
nalling data and data from multimedia streams associ- 
30 ated with the call. It may be required for wire-tap appli- 
cations, for example, to use the signalling data to identify 
calls of interest, and then capture the entire multimedia 
stream. It may be necessary to buffer captured packets 
at each location to ensure that all packets associated 
35 with the call could be captured. 

[0007] In addition, the packets associated with a con- 
ference call can be correlated together to form a service 
record for a conference call. This can be achieved by 
capturing all packets with the same conference ID in H. 
40 323, for example. 

[0008] In some cases it may be desirable to monitor 
additional signalling messages, e.g. Signalling System 
No. 7 (SS7) protocol messages or Integrated Services 
Digital Network (ISDN) messages, on signalling links in 
45 a switched circuit network (such as the public switched 
telephone network - PSTN) coupled to said packet data 
network, or Media Gateway Control protocol messages 
(for example MGCP or SGCP) which are used to control 
the gateway connection between the SON and the PDN, 
so to derive additional monitoring data, and correlate those 
additional monitoring data with at least some of first 
monitoring data. These can be correlated to the original 
call by using characteristics such as calling or called par- 
ty numbers to identify the call. 
55 [0009] Thus the invention can involve monitoring the 
control channels used for initiation, modification and ter- 
mination of multimedia sessions, and may include the 
monitoring of the multimedia channels themselves, to 
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provide a service detail record for a session. 
[0010] The invention enables a network operator to 
generate service detail records on a pure PDN, or on a 
hybrid network of interconnected PDNs and switched 
circuit networks (SCNs). There is also described a meth- 
od for automatically discovering the network configura- 
tion information, including addressing and identifying 
the relationships between gatekeepers and endpoints. 

Brief Description of Drawings 

[0011] Methods and apparatus In accordance with 
this invention for generating telephone service detail 
records will now be described, by way of example, with 
reference to the accompanying drawings, in which: 



Figure 1 shows a distributed monitoring system for 
a PDN carrying multimedia voice sen^ic- 
es; 

Figure 2 shows examples of extensions of this ar- 
chitecture to correlate data from the PDN 
with signalling data from the SCN; 

Figures shows the sequence of message types 
which can be captured to construct a serv- 
ice detail record; 

Figure 4 shows an example of the structure of a 
sen/ice record that coukJ be constructed 
from the data collected by the monitoring 
system; 

Figure 5 is a flow diagram of a process for monitor- 
ing signalling messages related to gate- 
keeper auto-discovery; 

Figure 6 is a flow diagram of a process for extract- 
ing data from gatekeeper auto-discovery 
messages; 

Figure 7 shows the relationship between the proc- 
esses of Figures 5 and 6; 

Figure 8 illustrates a failure mode which can affect 
the gatekeeper auto-discovery proce- 
dure; 

Figure 9 is a flow diagram of a process for monitor- 
ing signalling messages related to regis- 
tration of endpoints with gatekeepers; 

Figure 10 is a flow diagram of a process for extract- 
ing data from endpoint registration mes- 
sages; 

Figure 11 is a flow diagram of a process for extract- 
ing data from endpoint un registration 
messages; 

Figure 1 2 illustrates potentially anomalous registra- 
tion of endpoints with a gatekeeper in a 
different sub-net; 

Figure 13 illustrates potentially anomalous toad im- 
balance between two gatekeepers in a 
sub-net; 

Figure 14 is a flow diagram of a process for monitor- 
ing call signalling channels; 
Figu re 1 5 is a flow diagram of a process for monitor- 



ing call signalling messages; 

Figure 16 is a flow diagram of a process for monitor- 
in g control channels; and 

Figure 17 is a flow diagram of a process for monitor- 
s ing call signalling channels having dy- 

namic TSAP identifiers. 

Best Mode for Carn/ing Out the Invention. & Industrial 
Applicability 

10 

[0012] The distributed monitoring system shown in 
the drawings has the capability to collect data from a 
combined PDN and SCN carrying multimedia sen/ices, 
correlate these data in real-time, and provide a real-time 

IS view of services on the network. These data can be used 
for applications such as troubleshooting, surveillance, 
security, network planning, provision of accounting in- 
formation to customers, fraud detection, billing and ac- 
quisition of marketing information. 

20 [0013] Referring to Figure 1, the probes shown are 
part of the distributed monitoring system, and are pas- 
sive link monitoring devices (using techniques similar to 
those in existing protocol analysers for example). The 
distributed monitoring system is constructed from the 

25 probes and standard computer and communications 
components, with special-purpose software which pro- 
vides the applications described above. A principal func- 
tion of this software is to correlate data from different 
probes to provide a record or real-time trace of calls, 

30 transactions and other sen^ices as they occur on the net- 
work. The Hewlett-Packard accsSSZ system is an ex- 
ample of a distributed passive monitoring system which 
could be used to implement parts of the system de- 
scribed above. 

35 [0014] A Data Management Infrastructure (DMI) col- 
lects the data from the probes and processes the data 
to produce senrice detail records. The DMI may consist 
of software running on one or more computers, and the 
processing of the data and its storage may be distributed 

40 across these computers. The sen/ice detail record gen- 
eration process may be split between the probes and 
the DMI. The probes may generate partial sen^ice detail 
records by correlating all the information available on 
that probe about a particular session, and forwarding 

^ those partial records to the DMI. The DMI is then re- 
sponsible for correlation of partial service detail records 
from different probes to form the final sen/ice detail 
records. Alternatively the probes can forward uncorre- 
lated data to the DMI, and the DMI is then responsible 

so tor generating the complete sen^ice detail records. In 
both cases the DMI is also responsible for the storage 
of the service detail records and for providing interfaces 
for application programs to analyse the sen/ice detail 
records. This aspect of the DMI nr^y be implemented 

55 using data warehousing technology 

[0015] An example of a monitoring system architec- 
ture is given in Figure 2. This shows probes monitoring 
the PDN, SS7 network and the ISDN. The SS7 probes 
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could be for example from the Hewlett-Packard 
acc0SS7system. The ISDN primary rate access probes 
could for example be constructed using the same tech- 
niques as in existing protocol analysers (such as the 
Hewlett-Packard 37900D Signalling Test Set). The PDN 
probes could be constructed from Hewlett-Packard 
4986/7 or J3457/e LanProbes for exannple. 
[0016] The distributed monitoring system is arranged 
to correlate real-time data from any combination of 
these probes. This includes, for example, signalling data 
from the SS7 links, signalling from the ISDN links (e.g. 
the D-channel for narrowband ISDN), the signalling data 
for the multimedia service from the PDN, and the multi- 
media stream data (e.g. data indicating packet loss, la- 
tency or jitter). It may also include the capture of the en- 
tire multimedia stream for applications like wire tapping 
or troubleshooting. 

[0017] For convenience the invention is described pri- 
marily with reference to the H.323 reconnmendation. us- 
ing IP as the PDN, and optionally connected to one or 
more SCNs using narrowband ISDN and/or SS7 signal- 
ling with trunk connections. However, it should be un- 
derstood that this terminology is to be taken as including 
within its scope analogous functionality, whether or not 
they are customarily identified by the terms used in 
these standard recommendations. 

AUTO-DISCOVERY PROCESS 

[0018] The PDN is continuously monitored for pack- 
ets that provide configuration information on H.323 end- 
points and gatekeepers. These packets may be cap- 
tured to create and maintain a database (the network 
discovery database) which gives configuration informa- 
tion, addressing information and relationships between 
the endpoints and gatekeepers. The network discovery 
database may also take data from additional sources to 
supplement or verify the captured data. Any discrepan- 
cies between the discovered data and the data from oth- 
er sources should be used to generate an alarm to the 
network operator indicating a possible network configu- 
ration problem. The details of the data captured are de- 
scribed in the following paragraphs. 
[0019] A type of transaction which is tracked by the 
monitoring system is the gatekeeper discovery process. 
This is used by an endpoint to automatically find a gate- 
keeper which will provide service to it. The monitoring 
system uses the data captured from the sequence of 
messages between the endpoint and the gatekeeper, to 
identify endpoints and gatekeepers and to build a data- 
base of the relationships between endpoints and gate- 
keepers. The database stores information derived from 
the captured data which identifies the endpoint and 
gatekeeper. This includes the network addresses and 
port numbers. The monitoring system monitors contin- 
uously for endpoint discovery attempts, to maintain an 
accurate database of the network configuration. This 
monitoring process is described in more detail below 



with reference to Figures 5 to 8. 
[0020] The endpoint may go through a registration 
process with its gatekeeper. This process may be re- 
peated periodically if the registration has a finite lifetime. 

5 The monitoring system monitors the network continu- 
ously for packets involved in the registration process. 
The monitoring system captures the relevant packets 
and uses the data relating to the endpoint and gatekeep- 
er to update and add information to the database. This 

^0 typically includes any transport addresses (transport ad- 
dress = (Network address, Transport layer Service Ac- 
cess Point (TSAP) or port number)), any alias address- 
es and any other addressing or configuration informa- 
tion associated with the endpoint or gatekeeper. 

'5 [0021 ] Endpoints may also request from a gatekeeper 
location information for an endpoint for which it has the 
alias. The monitoring system will continuously monitor 
for the exchange of packets associated with this location 
process and capture data from the relevant packets. 

20 This data can be used to update or add infomnatbn to 
the network discovery database that identifies the rela- 
tionship between aliases, transport addresses and any 
other addressing or configuration Information. This may 
include information which identifies how to connect to a 

25 destination on the SON (e.g. E.I 64 addresses). More 
details of monitoring of the registration process are giv- 
en below with reference to Figures 9 to 13. 
[0022] Access tokens may be used to enable an end- 
point to hide Its transport address from the endpoint to 

30 which it is establishing communication. The monitoring 
system will continuously monitor the network to capture 
packets that are used in the process of distributing ac- 
cess tokens to endpoints. The captured data is used to 
add to or update information in the network database 

35 indicating the association between an access token and 
an endpoint. 

GENERATION OF SERVICE RECORDS 

40 [0023] This section lists the types of fields in sen/ice 
records, and describes how the distributed monitoring 
system could provide the required data. A sen/ice record 
is generated for each instance of the usage of a specific 
service. This is a generalisation of a call record, which 

45 is generated by current switches. A service is normally 
defined from the perspective of the user. The service 
may actually involve a number of calls or transactions, 
for example. In the case where only the PDN Is being 
monitored, these service records include data from the 

so signalling between any combination of gateways, gate- 
keepers, terminals and multi-point controllers; and data 
from the multimedia streams controlled by this signal? 
ling. In the case where the SCNs connected to the PDN 
are being monitored, the sen/ice record will also include 

55 data from the signalling data on the SCN collected from 
the probes connected to the SCN. The network discov- 
ery database may be used in constructing the sen^ice 
records to fill any address or configuration information 
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which is not available directly from the packets involved 
in the call. 

[0024] Figure 3 shows an exannple of the sequence 
of packets which may be captured at different levels in 
the overall stack of protocols (such as Q.931 . H.245 and 
an unreliable datagram protocol - UDP) to provide a 
service detail record. Figure 4 illustrates how the infor- 
mation from these different parts of the overall transac- 
tion can be used to contribute to different respective 
parts of a sen/ice detail record. 

1. Calling Party Information. 



service usage. The following are examples of data 
which might be provided: 

logical channels associated with the call and their 
5 identifiers, 

- the requested media, codecs (coder/decoders). 

sen/ice quality and bandwidth for each channel, 

the negotiated media, codecs, sen^ice qualrty and 

bandwidth for each channel. 
10 . any other performance or configuration data on the 

channels which are requested or established during 

the call or conference. 



[0025] This includes any information which can be de- 
rived about the calling party from the signalling data is 
flowing on the PDN, and is therefore available to the link 
monitoring probes. Typical information includes: calling 
party number; any ISDN sub-addressing information; 
calling party name; network addresses; TSAR or port 
numbers; alias addresses; and any numbers or ad- 20 
dresses related to billing. This information can be de- 
rived from the sequence of messages used to setup a 
call. In the H.323 recommendation, this can be achieved 
by extracting the relevant fields from the Q.931 messag- 
es used In setting up the call (set-up, call proceeding, 2$ 
alerting, connect for example). In the cases where one 
or more gatekeepers are involved the admission signal- 
ling (H.225 ARQ and ACF messages for- example) be- 
tween gatekeeper and endpoint is captured to identify 
the logical channel for call signalling. The togical chan- 30 
nel is typically identified using the transport address. 
[0026] Additional inf onmation may be derived from call 
setup messages on the ISDN D channels of an intercon- 
nected SON, at either the originating or terminating end 
or both; and/or from call setup messages on any of the 35 
SS7 links of the SCN. Additional information may also 
be derivedf rom any intelligent network sen/ice messag- 
es that flow over the SS7 links as part of the specific 
service usage. 

40 

2. Called Party Information. 

[0027] As for calling party infomiation, but replace 
calling party by called party. 

45 

3. Intormatbn on each party in a conference. 

[0028] The equivalent data to the calling party infor- 
mation for each party in a conference, with additional 
information on the conference objective (join confer- so 
ence, create conference or invite for example) and a 
means to identify the conference (Conference ID for ex- 
ample). 

4. Network Routing and Logical Channel Information. ss 

[0029] This may include any information on the net- 
work resources whrch were used to provide this specific 



Each of these uses is time-stamped, and the sequence 
and nature of the use indicated. These data can be ob- 
tained in a similar way as was described for item 1 above 
from the capture of packets carrying signalling informa- 
tion. More specifically the logical channels can be iden- 
tified by using the fields within an OpenLogicalChannel 
structure within certain messages defined in H.323 and 
associated recommendations. Subsequent messages 
which control the logical channels are also monitored 
and any changes in channel configuration can be time 
stamped and added to the service record. 
[0030] A important additional set of information is the 
measured quality of service and bandwidth usage on 
each of the logical channels set-up as part of the call. 
This will typically include packet loss rates, latency and 
jitter measurements which are made over selected in- 
ten^als by capturing packets from the bgical channels 
and extracting the relevant fields. 

5. Supplementary Sen/Ices Information. 

[0031] This may Include any information on supple- 
mentary sen^ices used for this specific senfice usage. 
The following are some examples of the data which may 
be provided: 

• call forwarding Indication and address information; 

interactive voice response information on the use 

of intelligent peripherals; 

800 number sen/ices; 
- any custom services that may be invoked during the 

call or conference. 

This information includes time-stamps, duration and the 
nature of the use. These data can be obtained in a sim- 
ilar way as was described for item 1 above. 

6. Sen^ice Status and Termination Information. 

[0032] This may include time-stamped information on 
the initiation of the sen/ ice, time-stamped information on 
any status changes occurring during service and time- 
stamped information on the terminatton of thesen/ice. 
The termination infonmation should include the reasons 
for termination. 
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[0033] These data can be obtained in a similar way 
as was described for item 1 above. In particular, the H. 
245 endSessionCommand message and the Q.931 call 
termination messages, the call clearing messages on 
the SS7 links and the ISDN D channels can provide de- 
tails on the reasons for call termination. 



itoring system can apply filtering criteria on any of the 
information described in the previous section, to select 
those instances of sen^ice use for which real-time up- 
dates are required. 

WIRE-TAP CAPABILITY 



7. Additional Service Quality Information. 

[0034] The service quality information provided is de- 
pendent on the service indicated in the service type field. 
The following gives some examples of what can be pro- 
vided tor specific services. 

[0035] Voice quality is main ty indicated by the bit en-or 
rate, jitter and delay. These parameters can be meas- 
ured using a passive monitoring system and monitoring 
at two points in the network. Signalling information can 
be used to identify the logical channels on the PDN, the 
ISDN B channels or the time slots on SON trunks, that 
are carrying the voice signals. The bit streams from each 
of the channels or trunk time slots identified can be com- 
pared to derive the delay, jitter and bit error rate caused 
by the intermediate networks. 

8. Service Usage Information. 

[0036] The type of usage data provided by the distrib- 
uted monitoring system depends on the specific service. 
Some examples follow. 

[0037] Voice, video and fax sen/ices require call du- 
ration and used bandwidth. 

[0038] The data oriented services require data such 
as total bits, frames and packets in each direction. This 
may be provided for regular time inten/als for the dura- 
tion of the service. It may also be broken down into a 
traffic matrix, where the data protocol has additional ad- 
dressing information (such as IP addresses). The data 
are obtained in a similar way as is described for item 1 
above. 

9. Security Infomfiation. 

[0039] A particular instance of service usage may be 
an attempt to obtain unauthorised access to resources. 
The service record includes information which may in- 
dicate this type of behaviour. This may include informa- 
tion about the duration of call, the way the. call was ter- 
minated and details of the service used. 
[0040] An example would be where there are repeat- 
ed failed attempts to gain access to different resources. 

REAL-TIME UPDATES ON SERVICE USE 

[0041] The data that populates the sen/ice records 
described in the previous section can be collected in re- 
al-time from the monitoring probes. These data can be 
provided in real-time on remotely connected computers, 
as they become available. A user of the distributed mon- 



[0042] Any of the data extracted from the signalling 
messages can be used to match criteria set by the user 

10 of the monitoring system and trigger some or all of the 
logical channels to be captured in their entirety. This 
technique can be used to provide a wire-tap capability, 
which would allow real-time copies of the media streams 
to be routed through the monitoring system to a third 

'5 party, or stored for analysis. The filtering could also be 
on characteristics in the media stream (for example, a 
specific spoken word in an audio stream) which, if 
matched, would trigger the capture of all the service 
record information from the signalling messages, as de- 

20 scribed earlier. 

APPLICATIONS 

[0043] The following applications can be implement- 
25 ed using the data from the sen/ice records described 
above or the real-time service updates. Data from other 
sources may be used to enhance the effectiveness of 
these applications. 

30 A. Quality of Sen/ice and Sen/ice Level Agreements. 

[0044] The service records described above can be 
used to provide service quality information on selected 
customer's sen/ice. This can be used to track conform- 
35 ance to service level agreements, and be provided to 
the customer as an additional sen/Ice. It can be provided 
as periodic reports, or in real-time using the real-time 
updates described above. 

40 B. Sun/eillance and Troubleshooting for Networi^ 
Operations. 

[0045] The service records and real-time updates can 
be used to identify sen/ice or network faults. The infor- 
4S nnation can also be used to troubleshoot the faults. 

C. Fraud Detection. 

[0046] The service records and real-time updates can 
so be used to Identify potential fraudulent use of the net- 
work or service. Indications may include excessive use 
of high value services, unusual call termination behav- 
iour and repeated failures to gain access to a service. 
The distributed monitoring system may be used to track 
ss the service usage of potential high-risk users in real- 
time. 
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D. Security and Hacking Detection 

[0047] Potential security threats can be identified by 
repeated failures to gain access to a service. They also 
may be indicated by successful access to sensitive serv- 
ices, such as maintenance ports on customer premises 
equipment (CPE). This type of data is available from the 
sen/ice records and the real-time updates. 

E. Billing Data 

[0048] The sen^ice records can be used as a basis for 
billing which is dependent on any of the fields in the serv- 
ice record. This allows, for example, billing to be based 
on the actual service quality delivered. It also enables 
billing to reflect the nature and generation of the usage 
of resources on the network, such as intelligent periph- 
erals and databases. The billing data could be made 
available in real-time. 

F. Customer Accounting Data 

[0049] The detailed sen/ice usage information in the 
service records can be provided to customers for use in 
their internal accounting. This includes the traffic matrix 
information for packet and frame based protocols, which 
the system derives from the B and D ISDN channels. 

G. Customer and Telecom Operator Network Planning 

[0050] The service records can provide detailed infor- 
mation on the use of network resources which can be 
provided to network planning departments within the op- 
erator and the customer. 

H. Wire-tap 

[0051] The wire-tap capability described above can 
be used to provide wire tap sen^ices to authorized third 
parties, and potentially as a trouble shooting tool. 

MONITORING OF H.323 GATEKEEPER DISCOVERY 
TRANSACTIONS 

[0052] As noted above, the gatekeeper discovery 
process is the process an endpoint uses to determine 
which H.323 gatekeeper to register with. The process 
can be performed manually or automatically. Manual 
discovery relies on information provided independently 
to the endpoint, and analysis of the endpoint registration 
procedure in this case can be used to Identify inconsist- 
encies In the available information. 
[0053] The discovery process starts when an end- 
point multicasts a Gatekeeper Request message (GRQ) 
to a predetermined address (Discovery Multicast Ad- 
dress). On receipt of such a message a gatekeeper can 
either accept (Gatekeeper Confirmation message - 
GCF) or reject (Gatekeeper Reject message - GRJ) the 



request. 

[0054] if several gatekeepers responds positively with 
GCF messages to the GRQ message, the endpoint is 
free to choose among them arbitrarily. In this case, anal- 

5 ysis of the choice of gatekeeper can usefully reveal if a 
suitable choice was made, or it can be used to verify 
assignment policies set by system managers. Analysis 
of the list of alternative gatekeepers is also worthwhile 
since it can provide information about network redun- 

10 dancy. 

[0055] Rejection messages and no^answers to GRQ 
messages are valuable since they enable verification of 
assignment policies as well as investigation of problems 
related to multicasting. 
IS [0056] Monitoring of the gatekeeper auto-discovery 
procedure is in this embodiment split into two process- 
es: 

Dispatcher process (Figure 5); and 
20 - SigProcessing process (Figure 6). 

[0057] Referring to Figure 5, the Dispatcher process 
collects all the GRQ, GCF and GRJ signalling messages 
detected by the link monitoring probes and determines 

25 the endpoint to which each refers. Then, as illustrated 
in Figure 7, the messages are dispatched to an appro- 
priate SigProcessing finite state machine (FSM) proc- 
ess which coordinates assembly of the data necessary 
to assess the gatekeeper auto-discovery procedure in 

30 relation to a specific endpoint. There need be only a sin- 
gle instance of the Dispatcher process, but several Sig- 
Processing processes can be active at the same time. 
[0058] Referring to the state definition language 
(SDL) chart in Figure 6. the SigProcessing process con- 

35 sists of an FSM which keeps track of the evolution of the 
gatekeeper auto-discovery process for a specific end- 
point. For the sake of clarity and simplicity, the chart has 
been designed with the assumption that the monitoring 
system is installed before endpoints start the gatekeep- 

40 er discovery process, in practice some endpoints might 
already be in the middle of the gatekeeper discovery 
process when the monitoring system is first installed. In 
this case a GCF or GRJ message is the first to be re- 
ceived in respect of such an endpoint, and the behaviour 

^ of the FSM shown in Figure 6 may be determined at the 
discretion of the system operator: incomplete informa- 
tion may be collected or, altematively, the signalling in- 
formation involved may be discarded. 
[0059] In relation to an endpoint, the measurements 

50 that can be collected and used to assess the overall 
gatekeeper auto-discovery process include: 

list of available gatekeepers (derived from GCF 
messages time-stamped and ordered); 
55 - list of gatekeepers that rejected the GRQ request 
(derived from GRJ messages time-stamped and or- 
dered); 

list of altemative gatekeepers; 
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- alarms (no answers to GRQ messages; GRQ re- 
transmissions too quick or too numerous); 

- wamlngs (RIP messages, i.e. gatekeepers too slow 

to answer). 

The 1 s» GRQ and the GCF or GRJ can be time-stamped 
and statistics about response times can be derived. 
[0060] Similar statistics can be also obtained for dis- 
covery process performance from the point of view of 
gatekeepers. 

[0061] The case of endpoints that do not receive any 
answer to their GRQs can be worthy of study. Two caus- 
es can be Identified for this behaviour: GRQs may be 
sent to a multicast address different from the predeter- 
mined Discovery Multicast Address, revealing mis-con- 
figuration at the endpoint; or, as shown in Figure 8, there 
may be configuration problems within a router causing 
the router to fail to fonward multicast requests from one 
sub-net to another. Clearly there is also the possibility 
of network disruption that occurred at the time an end- 
point Initiated the gatekeeper discovery procedure. For 
this reason it is important to keep a record of timing in- 
formation since it allows later correlation with other net- 
work events. 

[0062] The signalling messages involved in the gate- 
keeper discovery procedure and, in particular, the fields 
carrying key data for monitoring this procedure, are 
summarized below. This summary focuses on the es- 
sential fields, though more data can be extracted It de- 
sired from the signalling messages in order to provide 
more complete informatbn about the overall gatekeeper 
discovery process. 

Gatekeeper Request (GRQ) 

[0063] 

reqSeqNum. This allows correlation with subse- 
quent signalling (GCF and GFU messages) originat- 
ed in response to this request. 
rasAddress. Transport address of the endpoint 
(Registration, Admission and Status - RAS - chan- 
nel). 

endpointType. This identifies the type of endpoint 
(useful for consistency checks), 
gatekeeperldentifier. This should be empty. Other- 
wise, it contains the identifier of the gatekeeper the 
endpoint is interested in registering with. 

Gatekeeper Confirmation (GCF) 

[0064] 

reqSeqNum. Must be the same as in the corre- 
sponding GRQ message. 

gatekeeperldentifier. This Identifies the gatekeeper 
that is sending the GCF. 

rasAddress. Transport address used by the gate- 



keeper for registration and status messages. 

- alternateGatekeeper. Prioritised sequence ol alter- 
native gatekeepers and related RAS addresses. 

5 Gatekeeper Relect (GRJ) 

[0065] 

reqSeqNum. Must be the same as in the corre- 
10 spending GRQ message. 

gatekeeperldentifier. This identifies the gatekeeper 
that is sending the GRJ, 

rejectReason. Cause code related to this rejection. 

- alternateGatekeeper. Prioritised sequence of alter- 
15 native gatekeepers and related RAS addresses. 

altGKIsPermanent. This indicates if future RAS 
messages should be redirected to the alternative 
gatekeepers or not. 

20 MONITORING OF ENDPOINT REGISTRATION 

[0066] The endpoint registration procedure is comple- 
mentary to the gatekeeper discovery procedure, and en- 
ables an endpoint to join a "zone" managed by a chosen 

25 gatekeeper and inform the gatekeeper of its Transport 
Address and Alias addresses. Monitoring of this proce- 
dure enables the zone managed by one gatekeeper to 
be independently determined. It also allows correlation 
of the Information gathered during monitoring of the 

30 gatekeeper discovery procedure in order to assess the 
choice of specific gatekeeper by an endpoint. 
[0067] Registration is mandatory and must be done 
before any call is attempted. Furthermore, it may occur 
periodically according to the gatekeeper's policy. It 

35 might happen that the frequency of the registration proc- 
ess is very low and that therefore signalling related to 
the registration process is rarely captured. As an after- 
native monitoring of the admission procedure (e.g. ac- 
cording to recommendation H.225) can be used to cre- 

40 ate similar information to that gathered through monitor- 
ing of the registration process. 
[0068] The registration process involves only three 
signalling messages; usually it follows the gatekeeper 
discovery process. An endpoint sends a Registration 

45 Request message (RRQ) to a gatekeeper, using the 
gatekeeper's RAS address, which is known from the 
previous gatekeeper discovery process. On receipt of 
such a message the gatekeeper can either accept or 
reject the request and replies with a Registration Con- 

50 flrmation (RCF) or Registration Reject (RRJ) message, 
respectively. Reasons for rejection of the registration 
can include ambiguous registrations and security is- 
sues. 

[0069] The registration process can be periodically re- 
55 peated since each registration may have a finite life. 
Moreover, updates in an endpoint's Transport Address- 
es and/or Alias addresses are notified through new reg- 
istrations. 
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[0070] Closely related to the registration process is 
the unreglstration process, by which and endpoint and 
a gatekeeper cancel the relationship which exists be- 
tween them. Either an endpoint or a gatekeeper can in- 
itiate it. It also consists of three messages. The Unreg- 
ister Request (URQ) message triggers the procedure If 
initiated by a gatekeeper the endpoint has to acknowl- 
edge it by replying with an Unregister Confirmation 
(UCF) message. If initiated by an endpoint the gate- 
keeper might reply with an Unregister Reject message 
(URJ). This might be due to the fact that the endpoint 
was not in fact previously registered with this gatekeep- 
er. The unreglstration procedure may or may not be in- 
voked before a re-registration. 
[0071] A gatekeeper must keep a one-to-one map- 
ping between Transport and Alias addresses. Changes 
of both Transport and Alias addresses at once can occur 
and they should be preceded by use of the unreglstra- 
tion procedure. 

[0072] Monitoring of the registration procedure is val- 
uable for several reasons, tt can provide information 
needed to define zones and provide a mapping between 
Transport Addresses and Aliases. Furthermore, securi- 
ty policies can be monitored and verified and, eventual- 
ly, fraud or fraud attempts discovered. Gatekeeper load 
balance can also be usefully analysed. Finally, mapping 
of the endpolntsthat belong to a zone in conjunction with 
depiction of the physical representation of the network 
topology (e.g. derived using auto-discovery facilities In 
the Hewlett-Packard OpenView network management 
tool) can be extremely useful to Identify network prob- 
lems such as connectivity bottlenecks or unsuitable 
gatekeeper choices. 

[0073] As mentioned earlier, the admission procedure 
can be used similarly to the registration procedure to 
generate data about the zone discovery. In this case, 
algorithms similar to those described herein can be used 
by replacing RRQ with ARQ, RCF with ACF and RRJ 
with ARJ, respectively 

[0074] Processing of the registration and unreglstra- 
tion signalling is split Into two. A first Dispatcher process 
(shown in Figure 9) recognises if any of the registration 
or unregistration messages that are captured refers to 
any endpoint already registered or in the process of do- 
ing so. As illustrated by reference again to Figure 7, the 
Dispatcher process also dispatches the signalling mes- 
sage to one of two SigProcessing processes which ex- 
tract the data necessary for zone discovery, SDL charts 
for these two processes are shown in Figure 1 0 (regis- 
tration) and Figure 11 (unregistration), respectively. 
[0075] The measurements that can be collected in 
this way and used to generate data about zones include: 

endpoint < — > gatekeeper relationship (dynamic re- 
lationship); 

Transport Address < — > Alias Address correspond- 
ence (dynamic relationship); 
gatekeeper load balance; 



alarms (no answers to request messages); 
warnings (RIP messages, i.e. gatekeepers too slow 
to answer); 

mapping of a zone over the physical network topol- 

5 ogy; 

assessment of the choice by endpoints of the gate- 
keeper to register with; 

analysis of rejections of registration and unregistra- 
tion attempts. 

70 

The endpoint-gatekeeper relationship Is a temporal re- 
lationship which has a related start. and end time. Simi- 
larly, the identification ot endpoints through Alias and 
Transport Addresses is dynamic and it must be associ- 
ated with timestamps. Consistency checks should pref- 
erably be carried out to verify that a unique mapping ex- 
ists between an Alias Address and the related Transport 
Address. 

[0076] It is possible to highlight cases of endpoints 
20 that do not receive any answer to RRQ or URQ mes- 
sages. This might be due, lor example, to the use of an 
incorrect gatekeeper RAS address. The information 
gathered about the registration procedure can be used 
to assess the choice of gatekeeper with which endpoints 
25 register and, ultimately, to determine abnornrial configu- 
rations. 

[0077] Moreover, it is useful to map zones relative to 
physical network topologies. For example, Figure 12 
shows two sub-nets, each with a gatekeeper and sev- 

30 eral endpoints. More specifically, two endpoints in the 
sub-net A are registered with a gatekeeper GKg that is 
associated with another sub-net. sub-net B. This may 
be a desirable behaviour justified by gatekeeper load 
balancing policies. However, it might also be anomalous 

35 behaviour. 

[0078] With regard to gatekeeper load balance, Fig- 
ure 1 3 shows schematically the traffic between the end- 
points and the gatekeepers on the same sub-net. Clear- 
ly load imbalance exists between the two gatekeepers. 

40 As in the previous case, this may be a desirable behav- 
iour. But it might also reveal the existence of a situation 
that does not match the desired policy put in place by 
the system administrator. 

[0079] Rejection messages, such as RRJ or URJ, can 
4S be useful to highlight either configuration or security re- 
lated problems, e.g. fraud attempts. 
[0080] The signalling messages involved in the regis- 
tration and unregistration procedure and, in particular, 
the fields that carry the key data for the monitoring of 
so these procedures, are summarized below: 

Registration Request (RRQ) 

[0081] 

55 

requestSeqNum. Monotonically increasing number 
unique to the sender. 

discoveryComplete. Set to TRUE if the registration 
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follows the gatekeeper discovery process. It could 
happen that when a registration ages, the gate- 
keeper discovery has to be invoked before attennpt- 
ing a new registration. This is one possible reason 
for rejecting an RRQ or ARQ. 
caliSignalAddress. Call signalling address for the 
endpoint. 

ras Address. Transport address of the* endpoint 
(RAS channel). 

terminalType. This identifies the type of endpoint 
(useful for consistency checks). 
ternDinalAlias. This should be empty Otherwise, it 
contains a list of Aliases to identify the endpoint. 
Gatekeeperldentifier The gatekeeper with which 
the terminal wishes to register. 
altemateEndpoints. A sequence of endpoint alter- 
natives for CallSignaliingAddress, rasAddress, ter- 
nninalType, or terminalAlias. 

Registration Confirmation (RCF) 

[0082] 

requestSeqNum. Same value as for the RRQ. 
caliSignalAddress. Transport Addresses for H. 
255.0 signalling. 

ternninalAlias. A list of Alias Addresses assigned by 
the gatekeeper by which other terminals Identify the 
endpoint. 

Gatekeeperldentifier. The gatekeeper that has ac- 
cepted the endpoint registration. 
timeToLive. Duration of the validity of the registra- 
tion. 

preG ranted ARQ. Special pre-granted permission 
to make phone calls. 

Registration Reject (RRJ) 

[0083] 

requestSeqNum. Same value as for the RRQ. 
rejectReason. The reason for the rejection of the 
registration. 

Gatekeeperldentifier. The gatekeeper that has re- 
jected the endpoint registration. 
altemateGatekeeper. Sequence of prioritised alter- 
native gatekeepers with which to retry requests. 
altGKisPermanent. True or False. Indicates if all 
subsequent messages are to be redirected to the 
alternative gatekeepers. 

Unregistration Request (URQ) 

[0084] 

requestSeqNum. Monotonically increasing number 
unique to the sender. 

caliSignalAddress. Call signalling address for the 



endpoint. 

reason. Reason for the unregistration initiated by 
the gatekeeper. 

s Unregistration Confirmation (UCF) 

[0085] 

requestSeqNum. Same value as for the URQ. 

10 

Unregistration Reject (URJ) 
[0086] 

IS - requestSeqNum. Same value as tor the URQ. 

rejectReason. The reason for the rejection of the 
unregistration. 

altemateGatekeeper. Sequence of prioritised alter- 
native gatekeepers with which to retry requests. 
20 - altGKisPermanent. True or False. Indicates if alt 
subsequent messages are to be redirected to the 
alternative gatekeepers. 

EXAMPLE 1 - Two Endpoints Communicating 
25 Directly without a Gatekeeper 

[0087] In this first example it is assumed that: 

the underlying network is an IP network, TCP is 
30 used to provide reliable connections and UDP is 
used to provide unreliable connections; 
the two endpoints communicate directly without the 
use of a gatekeeper - this simplifies the process be- 
cause the Call Signalling Channel uses a "well- 
35 known" TSAP identifier (specified in recommenda- 
tion l-t.225); the case where the Call Signalling 
Channel is identified through an interaction with a 
gatekeeper is described in Example 2 below; 
there are only two endpoints, which initiate one or 
^ more audio or video connections using Real Time 
Protocol (RTP); 

the call is not modified during the session, for ex- 
ample by adding new participants or requesting 
changes in bandwidth; 
- the Call Signalling Channel remains open for the 
duration of the session, and a RELEASE COM- 
PLETE message is used to terminate the session. 

[0088] The finite state machine processes required to 
so monitor this type of session are as follows: 

1. Call Signalling Channel FSM (see Figure 14) 

[0089] This monitors all links continuously looking for 
55 a reliable-connection setup (for example, the SYN of a 
TCP connection) using the well-known TSAP identifier 
for the Call Signalling Channel. In response to a Call 
Signalling Channel being established, this process ini- 
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tiates a new Call Signalling Message FSM (CSM-FSM 
- see item 2 below) to monitor the Channel and passes 
to it the transport addresses of the two endpoints. 

2. Call Signalling Message FSM (see Figure 15) 

[0090] This is initiated to monitor a specific Call Sig- 
nalling Channel, and is terminated when the reliable 
connection is terminated tor that Channel (tor example, 
by the FYN of the TCP connection). It continuously mon- 
itors the Channel for signalling messages. A SETUP 
message indicates the start of a new call, and causes 
the process to create a new service detail record (SDR) 
for the call. The call identifier is used to uniquely identify 
the sen/Ice detail record for the duration of the call, and 
to identify subsequent call signalling messages. The 
service detail record is populated with a time stamp, and 
any useful fields from the SETUP message. 
[0091] The CONNECT message sent from the called 
endpoint normally carries the transport addresses to be 
used for the H.245 Control Channel. In response to this 
message an H.245 Control Channel FSM (HCC-FSM - 
see item 3 below) Is started, to monitor the H.245 sig- 
nalling tor the session. The service detail record is pop- 
ulated with an additional time stamp if required, and any 
of the useful fields from the CONNECT message. 
[0092] A RELEASE COMPLETE message indicates 
the termination of the session. The sen/ice detail record 
is updated with any relevant data and time stamps, and 
then closed. The H.245 Control Channel FSM monitor- 
ing the H.245 signalling is terminated. However, moni- 
toring for subsequent signalling messages is continued 
in order to capture further calls between the two end- 
points. 

[0093] The main paths in this FSM are shown in Fig- 
ure 1 5; however in the interests of clarity error conditions 
have been omitted. The capture of other signalling mes- 
sages, particularly those involved in modifying calls, 
could also be captured and used to update the sen/ice 
detail record with additional information and time 
stamps. It may also be required to initiate further FSMs 
to monitor other aspects of the call. 

3. H.245 Control Channel FSM (see Figure 16) 

[0094] This is initiated from the Call Signalling Mes- 
sage FSM and monitors all messages on the H.245 
Control Channel for the duration of the call. The FSM is 
terminated by the detection of an endSessionCommand 
message on the H.245 Control Channel. Logical chan- 
nels are opened and closed using the openLogical- 
Charinel and closeLogicalChannel messages. The FSM 
detects the opening of a Channel, extracts the relevant 
data and initiates two new FSMs to monitor the forward 
and reverse Real Time Control Protocol (RTCP) con- 
nections (RS-FSMs - see item 4 below). A logical Chan- 
nel is uniquely identified by the Logical Channel Number 
(LCN). This is used to identity the RS-FSMs to be ter- 



minated when the closeLogicalChannel messages are 
received. 

[0095] The main process paths are indicated in Figure 
16; however there are many more messages on the 
5 Control Channel which could be captured to provide ad- 
ditional information in the sen^ice detail record. 

4. RTCP Session FSM 

70 [0096] The RTCP connection provides detailed infor- 
mation on the performance of the RTP connection that 
it controls. This can be captured as required to provide 
quality of service Information in the service detail record. 
The RTP stream itself may be monitored at multiple 

IS points in its path to make quality of sen/ice measure- 
ments which can be added to the sen^ice detail record. 

EXAMPLE 2 -Endpoints Communicating via a 
Gatekeeper 

20 

[0097] When a gatekeeper is involved the Call Signal- 
ling Channel may no longer be carried on the well- 
known Transport Address; instead a dynamic TSAP 
identifier which the endpoint obtains from the gatekeep- 
25 er may be used. The FSM for this situation is shown in 
Figure 17. This process uses the information about 
gatekeepers and endpoints acquired during the gate- 
keeper discovery process. The RAS Channel between 
all gatekeepers and endpoints is continuously moni- 

30 tored for control messages. An Admission Request 
(ARQ) followed by an Admission Confirmation (ACF) 
means that the endpoint has requested to setup a call 
and has been allowed to do so by the gatekeeper. The 
Transport Address which will be used for the Call Sig- 

3S nailing Channel can be obtained from the Admission 
Confirmation message. A Call Signalling Message FSM 
is initiated to monitor the reliable connection for that 
Transport Address. The remainder of the processing 
proceeds in a similar manner to Example 1. 

40 [0098] The example in Figure 17 shows the generic 
case of simply identifying the Call Signalling Channel. It 
Is straightton/vard to extend this to include the creation 
of the service detail record in response to an Admission 
Request message from the endpoint to the gatekeeper 

45 This enables the creation of service detail records which 
include information and time stamps taken from the call 
related messages on the RAS Channel. It also enables 
the generation of sen/ice detail records in the case 
where an Admission Reject message is received and no 

so Call Signalling Channel is ever established. 

[0099] The presence of gatekeepers may also affect 
the call clearing process. Typically a disengage request 
(DRQ) message is transferred between the endpoint 
and the gatekeeper as part of the call clearing process. 

ss [0100] The Call Reference Value (CRV). in cases 
where it is implemented by vendors, can be used 
throughout the call as a unique identifier for all the mes- 
sages. 
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[0101] The processes described above can be split in 
many different ways between the probes and the other 
processors in the Distributed Management Infrastruc- 
ture. There are established methods for choosing how 
to distribute the processing; the Hewlett-Paclcard 
access? architecture provides one example of how this 
may be achieved. 

Claims 



generalised sen^ice detail records. 

9. The method of claim 8, including use of data col- 
lected from passive monitoring of a signalling net- 

5 work (e.g. SS7) or access signalling (e.g. ISDN, B- 
ISDN). 

10. The method of claim 8, including use of data col- 
lected from the switched circuit network for audio or 

10 video quality. 



1. A method of generating generalised service detail 
records for communications carried over a packet 
network, comprising the steps of: 

acquiring packet network service data from 
packets carrying the communications; 
acquiring signalling data from a signalling pro- 
tocol to identify at least one of addressing, con- 
figuratbn, status and timing information for 
endpoints, gatekeepers and connections in- 
volved in a call; and 

combining said packet service data and said 
signalling data to generate sen/ice detail 
records. 

2. The method of claim 1 , wherein some or all of the 
data are captured by a passive monitoring system. 

3. The method of claim 1 or clainn 2, wherein packet 
network sen/ice data are acquired from the protocol 
headers of the packets carrying the signalling data 
for the sen/ice. 

4. The method of any one of the preceding claims, in- 
cluding using the information identified from the sig- 
nalling data to identify the logical channels carrying 
the media streams, and capture some or all of the 
packets on the logical channels in real-time at one 
or more points in the network. 

5. The method of claim 4, wherein captured data are 
used to measure the quality of service actually 
achieved by each channel. 

6. The method of claim 4, wherein captured data are 
used to provide secret access to the media stream 
for troubleshooting or sun^eillance purposes. 



IS 



20 



25 



30 



35 



40 



45 



1 1 . The method of any one of the preceding claims, in- 
cluding using the generalised service detail records 
to bill for the service, optionally taking into account 
the quality of service and usage data, and optbnatly 
including tracking to see if customers have been ex- 
ceeding their agreed bandwidth constraints. 

12. The method of any one of the preceding claims, in- 
cluding using the generalised sen/ice detail records 
to detect potentially fraudulent sen/ice usage, per- 
form network planning, perform marketing studies, 
perform network operations functions, modify the 
network configuration in real-time to achieve quality 
of service objectives, and/or perform customer care 
functions. 

13. A method of discovering the network configuration 
of the endpoints, gatekeepers and their relation- 
ships, for a communications service carried by a 
packet network, by using a passive monitoring sys- 
tem to capture the signalling messages involved in 
the configuration and negotiation of relationships, 
addressing and resource allocation, between end- 
points and gatekeepers. 

1 4. The method of claim 1 3, wherein the signalling mes- 
sages captured are gatekeeper request, gatekeep- 
er confirmation and gatekeeper reject messages. 

15. The method of claim 14, wherein data are extracted 
from the captured signalling messages to identify at 
least one of the following types of information: avail- 
able gatekeepers, alternative gatekeepers, gate- 
keepers rejecting request messages, endpoints 
which receive no response to request messages, 
and gatekeepers which are excessively slow to re- 
spond to requests. 



7. The method of claim 6; wherein addressing intor- 50 
mation for the target user is used to select the cor- 
rect signalling packets, potentially in conjunction 
with data from a network discovery database. 

8. The method of any one of the preceding claims, in- S5 
eluding correlating the data from the packet network 
with data collected from a switched circuit network 
(such as a PSTN, ISDN or B-ISDN) to enhance the 



16. The method of claim 1 3, wherein the signalling mes- 
sages captured are endpoint registration request 
messages and associated registration confirmation 
and reject messages. 

17. The nhethod of claim 1 6, wherein data are extracted 
from the captured signalling messages to Identify at 
least one of the following types of infornnation: rela- 
tionships between gatekeepers and endpoints, cor- 
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relations between Transport Addresses and Alias 
addresses, gatekeeper load balance, endpoints re- 
ceiving no response to request messages, gate- 
keepers which are excessively slow to respond to 
requests, correlation between gatekeeper zones s 
and physical network topology, choice by endpoints 
of gatekeepers with which to register, and rejections 
of registration requests. 

18. A method of generating generalised service detail io 
records for communications carried over a packet 
network, comprising the steps of: 

acquiring packet network service data for the 
packets carrying the communications service; 
acquiring signalling data regarding at least one 
of call control, registration, admissions, band- 
width management, call status, address trans- 
lation and intelligent network services; 
acquiring quality of service data for the sen/ice 20 
transmission level; and 

combining said service data, said signalling da- 
ta and said quality of service data to generate 
generalised service detail records. 

25 

19. The method of any one of the preceding claims, 
wherein the capture of packets is perfonmed at mul- 
tiple points in real time, and then correlated in real- 
time. 

30 

20. The method of any one of the preceding claims, 
wherein the communications comprise real-time 
voice or audio, fax, voice-messaging, real time vid- 
eo or multimedia communications. 

35 

21. The method of any one of the preceding claims, 
wherein the packet network is an IP. frame relay or 
ATM network. 

22. A method of monitoring a packet data sub-network 40 
or link, comprising the steps of: monitoring at a first 
location signalling messages to detect the exist- 
ence of a call; and monitoring at multiple other lo- 
cations to identify some or all packets associated 
with the call. ^ 
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